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REMARKS 

AppUcants respectfidly request that the above-identified application be re-examined. 

The March 25, 2004, filial Office Action ("Office Action") rejected all of the claims 
(1-23) of the above-identified application. Claims 13-19 and 21-23 were rejected under 
35 U.S.C. § 1 12, second paragraph, for inclusion of a teim without antecedent basis. This 
amendment amends Claims 13 and 21-23 in a manner directed to eliminating this formaUty. In 
addition, the Office Action rejected Claims 1-5, 7-9, 12, 20, and 22 under 35 U.S.C. § 103(a) as 
being unpatentable in view of the teachings of U.S. Patent No. 6,233,624 (Hyder etal.) taken in 
view of the teachings of U.S. Patent No. 6,385.663 (Senator). Claims 6, 10-U, 13-19, 21, 
and 23 were rejected under 35 U.S.C. § 103(a) as being unpatentable in view of the teachings of 
Hyder et al. taken m view of the teachings of Senator and U.S. Patent No. 5,978,815 (Cabrera 
etal.). 

Prior to discussing the reasons v/hy applicants believe that the amended claims in this 
application are allowable, a brief discussion of the present invention, followed by a brief 
discussion of the cited and appUed references, is presented. The following discussion of 
applicants' invention and the cited and applied references is not provided to define the scope or 
interpretation of any of the claims in this apphcation. Instead, these discussions are provided to 
help the United States Patent and Trademark Office ("the Office") better appreciate important 
claim distinctions discussed thereafter. 

Summary of the Invention 

The present invention addresses one of the shortcomings of supporting a kernel mode 
driver that provides management and diagnostic data in enterprise networks, namely, the burden 
associated with the need for manufacturers to independently develop software methods and 
functions to mcorporate into device drivers in order to support a device driver monitor and 
control management system, such as the Windows Management Instrumentation C'WMI") 
system. A device driver monitor and control management system, such as the WMI system, 
monitors information provided by and actions performed by device drivers and issues messages 
to device drivers. 

The prior art need for manufecturers to independently develop software methods and 
functions to incorporate into device drivers has created a burden shared by every developer of 
device drivers intended to be used with a device driver and monitor control management system. 
Additional time is required for each developer to produce both the code specific to the 
developer's device and the code specific to the device driver and monitor control management 
system. Further, because similar code is often included in the device drivers that support the 
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device driver monitor and conlrol management system, functionally identical code is often 
loaded into memory by several drivers. TTie result is an inefScient operation that requires more 
overhead than necessary to support the device driver and monitor control management system. 
Overall system performance may sujEfer. Also, the likelihood of encoding errora or "bugs" is 
mcreased due to many disparate developers creating code that performs substantially the same 
function. 

The present invention addresses the above-described needs and disadvantages by 
providing a set of common software routines that may be accessed by device drivers in support 
of a device driver monitor and control management system that monitors infonnation provided 
by and actions performed by device drivers and that issues messages to device drivers. The set 
of common routines includes typical routines that would ordinarily be executed by device drivers 
designed to function with such a device driver monitor and control management system. The 
common routines reside in a library, dynamically accessible by the device drivers. When a 
device driver receives a message from such a device driver monitor and control management 
system, if appropriate, the device driver passes the message to the library to be handled in a 
common manner. In this manner, the developers of device drivers that support the device driver 
monitor and control management system need develop only the code necessary to support any 
unique features or data storage of the hardware associated with the device drivers. The result is 
shortened development time and fewer programming errors. In addition, overall system 
performance may be improved because fewer instances of similar code are loaded in memory to 
support the device driver monitor and control management system. The present invention is 
particularly advantageous in enterprise networks, i.e., networks that include multiple devices, 
such as printers, fex machines, etc., that interact with multiple driving sources, such as 
computers, work stations, etc. 

One exemplary embodiment of the present invention provides an extension to a device 
driver operathag in kernel mode. This exemplary embodhnent allows instrumentation data, such 
as data to configure device settings and supply event notification from device drivers, to pass 
between user and kernel mode, Such data passage allows a device driver monitor and control 
management system that monitors information provided by and actions performed by device 
drivers and that issues messages to device drivers to access device drivers, even if they are kernel 
mode drivers. Device driver monitor and control management system access is provided by a set 
of common software routines that may be accessed by device drivers in support of the device 
driver monitor and control management system. The conunon routines include typical routines 
that would ordinarily be executed by device drivers designed to operate with a device driver 
monitor and control management system that monitors information provided by and actions 
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peifonned by device drivers and that issues messages to device drivers. The common routines 
reside in the common driver Hbrary accessible by the device drivers. When a device driver 
receives a message fix>m the device driver monitor and control management system, if 
appropriate, the device driver passes the message to the library to be handled in a common 
manner. 

In addition to the other advantages described above, the use of common routines stored in 
a library allows the stored routines to be modified without affecting the related drives so long as 
each driver's interface to the library is maintained. 

U.S. Patent 6.?^3.624 CHvder et al) 

Hyder et al. provides a system for incorporating a link layer intermediate driver into a 
data flow path in a computer operating system. The data flow path is a path of execution that is 
traversed through a network protocol stack. The network protocol stack defines a data flow path 
through which data is passed between a transport layer and a physical device connected to a 
network. Generally, a network protocol stack comprises a transport layer driver, one or more 
link layer intermediate drivers, and a link layer device driver interfacing with the physical 
hardware or device. The link layer intermediate driver receives data and returns processed data 
through an abstract interface while a link layer device driver is comprised of an mteriace with the 
abstract interface and a separate interface with the physical device. The abstract interface is 
comprised of a function Hbrary, which handles many of the details involved in managing 
synchronous and asynchronous communications across a network. The abstract interfece also 
provides a Ubrary of functions for interfacmg with the kernel mode of an operating system. 
Device drivers, therefore, need only perform hardware-specific operations needed to manage a 
particular piece of hardware or physical device. In contrast, traditional drivers inherently 
incorporate most of the above fimctionality, which malces such device drivers much harder to 
write to and debug, and these device drivers often operate slower. 

Essentially, Hyder et al. discloses providing a driver library separate fi»m a device driver. 
As recognized in the Office Action, Hyder etal. does not disclose, teach, or suggest a device 
driver monitor and control management system that monitors information provided by and 
actions performed by device drivers and that issues messages to device drivers, let alone such a 
device driver monitor and control management system in communication with device drivers. 
This functionality is clearly not provided by TRANSPORT 132, Figure 2, 

U.S. Patent No. 6.385.663 rSenatnt-^ 

Senator purportedly discloses a device I/O monitoring mechanism for a computer 
operating system. The device I/O monitoring mechanism serves as an interface between a 
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computer operating system kernel and a device driver. The I/O momtoring mechanism obviates 
the necessity of implementing specific pseudo-device drivers for various peripheral devices and 
provides a standard interfece between, for example, computer mass storage devices and a 
computer operating system. The I/O monitoring mechanism is allegedly of especial utility in the 
measurement of general storage device FO performance and allows I/O statistics to be presented 
to application-level software operating in conjunction with a computer operating system, Col. 2, 
lines 19, «r seq., state that the method comprises: intercepting one or more selected calls from a 
computer operating system to a device driver; providing for initiating a call back to a portion of 
the operating system to record an occurrence of one or more selected caUs; and providing for 
passing the one or more selected calls to the device driver. The method may also comprise 
further intercepting one or more selected calls to the device driver to the computer operating 
system; further initiating an additional caU back to the operating system to record an occurrence 
of the one or more selected device calls; and further passing the one or more device caUs to the 
operating system. In other words, Senator teaches an I/O monitoring system for monitoring calls 
between a computer operating system and a device driver, and nothmg more. 

U.S. Patent 5.9 78.815 <^Cabrera at > 

Cabrera etal. purportedly discloses a model where a plurality of drivers or client 
processes cooperate to fulfiU an input/output ("I/O") request The drivers or data managers may 
have a layered relationship to each other such that each is responsible for processing a particular 
portion of an I/O request Information may be passed from one driver to another driver using I/O 
request packets ("IRPs") so that all drivers cooperate to fUfill an I/O request. 

Like Hyder et al. and Senator, Cabrera et al. does not disclose, teach, or suggest a device 
driver monitor and control management system that monitors information provided by and 
actions performed by device drivers and that issues messages to device drivers. 

Rejection of Clauns 13-19 and 21-23 TTnder U.S C!. § 11? 

Independent Clahns 13 and 21-23 have been amended so as to replace "the" before the 
first occurrence of device driver with "a" in line 3 of each of these claims. As a result, applicants 
submit that an antecedent basis now exists for "the device driver" in Claims 13-19 and 21-23, 
thereby eliminating this grounds of rejection. 

Rejection of Claims 1-S. 7-9. 12. 20 and 22 Under ^5 U.S.C. lQ2re) 

For the reasons set fortii below, applicants respectfully submit that the 35 U.S.C. § 103(a) 
rejection of Claims 1, 20, and 22 and the claims dependent from Claim 1, listed above, is clearly 
in error, should be withdrawn, and these claims allowed. These claims are clearly not 
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ynpatentable in view of the teachings of Hyder et al. and Senator. In this regard, Claim 1 reads 
as follows: 

1. A computer-readable medium having computer-executable 
components, comprising; 

a device driver configured to provide information and perfomi actions 
associated with a hardware device; and 

a driver Ubrary containing software routines for making the infonnation 
provided by and the actions performed by the device driver accessible to a device 
driver monitor and control management system that monitors infonnation 
provided by and actions performed by the device driver and that issues messages 
to the device driver, the software routines of the Ubwiy being accessible by the 
device driver to handle messages issued to the device driver by the device driver 
monitor and control management system, 

Claim 1 clearly recites a "device driver monitor and control management system that 
monitors information provided by and actions performed by the device driver and that issues 
messages to the device driver." Similar language is included in Claims 20 and 22. 

AppUcants submit that the OfEce Action's conclusion that TRANSPORT 132, 
FIGURE 2, is a teaching of a device driver momtor and control management system of the type 
recited in independent Clauns 1, 20, and 22 is clearly in error. More specifically, applicants 
respectfiilly submit that TRANSPORT 132 is clearly not a device driver momtor and control 
management system that monitors information provided by, and actions performed by, a device 
driver and that issues messages to a device driver. In this regard, attention is again directed to 
Column 5, lines 53-59, of Hyder et al. which reads as follows; 

A transport layer driver 132 receives data destined for dispatch across a network 
via hardware or physical devices such as physical devices 152 and 154. Transport 
layer driver 132 petfonns packetization and formatting of bulk data into packets 
compatible for transfer across a network. Transport layer driver 132 is 
responsible for implementing a specific network protocol such as TCP/IP or 
IPX/SPX. 

In other words, TRANSPORT layer 132 simply performs bulk data formatting and packets the 
fomiatted data into packets compatible for transfer across a network. Transport layer 132 is not 
a device driver monitor and control management system, much less a device driver monitor and 
control management system that monitors information provided by and actions performed by a 
device driver and issues messages to a device driver as recited in Claims 1, 20, and 22. 

While the Office Action does not recognize that Hyder et al. does not disclose any type of 
device driver momtor and control management system that monitors information provided by 
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and actions performed by a device driver and issues messages to a device driver, the Office 
Action does recognize that Hyder et al. does not explicitly teach such a device driver conHol and 
management system. This deficiency is allegedly made up by the disclosure of Senator. As 
discussed more fully below. Senator does not make up for the deficiencies of Hyder et al. More 
importantly, there is no teaching or suggestion in either Hyder etal. or Senator how their 
individual teachings could be combined in any manner, much less the manner recited in the 
rejected claim. Further, even if combinable, the resulting combination would not meet all of the 
limitations of the rejected claims. 

As noted above, Senator discloses intercepting one or more selected calls between a 
computer operating system and a device driver, initiating a call back to a portion of the operating 
system to record the occurrence of the one or more selected caUs, and providing for the passing 
of the selected calls to the receiving device, i.e., the operating system or the device driver. At 
best, Senator discloses a monitoring system. More importantly, there is no teaching or 
suggestion in either Hyder etal. or Senator as to why their individual teachings should be 
combined in any manner, much less the manner suggested in the claims. Hyder et al. discloses a 
transport layer driver that packetizes and formats bulk data into packets for transfer across a 
networic. Senator discloses a monitoring system. Neither reference teaches nor suggests why a 
person of ordinary skiU in the art would add a monitoring system to the Hyder et al. iransport 
layer driver, This is only suggested by the present application. The Office Action's statement: 

It would have been obvious to apply the monitoring functionality of the 
pseudo-device driver of Senator to the device driver control management system 
(transport 132, Fig. 2) of Hyder because this allows the statistics of the device 
drivers to be sent to applications programs; therefore, such statistics could be used 
by the system to determine the levels of performance of the device drivers. 

is clearly using hindsight reasoning based on the present appUcation, not the teachings of the 
references. Such hindsight reasoning is clearly inappropriate in reaching an obviousness 
conclusion, as well documented in the case law. 

Because Hyder et al. and Senator do not teach or suggest the subject matter of Claims 1 , 
20, and 22, and since neither reference teaches nor suggests how or why it would be obvious to 
combine the individual teachings of these references, appHcants further submit that the rejection 
of Claims I, 20, and 22 under 35 U.S.C. § 103(a) is clearly in error, request that this rejection be 
withdrawn, and Claims 1, 20, and 22 allowed. 

As Claims 2-5, 7-9, and 12 all depend from allowable Claim 1, these claims axe 
submitted to be allowable for at least the reasons noted above. 
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ClaitQs 2-5, 7-9, and 12 aU contain additional recitations that further distinguish them 
fiom the teachings of Hyder et al, and, thus, are submitted to be allowable for additional reasons 
For example, Claim 7 recites that a unique software routine (added in Claims 2 and 3, the claims 
from which Claim 7 depends) "is configured to execute a method associated with the information 
associated with the hardware device, the method being operative to pass additional information 
between the device driver and the device driver monitor and control system or perform a certain 
action." There is no teaching, disclosure, or suggestion m Hyder et al. or Senator of a software 
routine that is configured to execute a method associated with ihe information associated with 
the hardware device, and operative to pass additional information between the device driver and 
a device driver monitor and control management system that performs the functions recited m 
Claim 1 . Accordingly, Clahn 7 and its dependent claim. Claim 8, are submitted to be allowable 
for this reason as well. 

Rejection of Claims 6. 10-71 , 13-19. 21. and 23 Under .35; TJ.S.C. $ in:^^^ 

Independent Claims 13, 21, and 23 were previously amended to more clearly point out 
and distinctly claim Ihe present mvention. For the reasons set forth below, appUcants submit that 
the 35 U.S.C. § 103Ca) rejection of these claims, and the clauns dependent from Claim 1 Hsted 
above, is clearly in error, should be withdrawn, and these claims allowed, Neither Hyder et al.. 
Senator, nor Cabrera et al., taken alone or in combination, teaches or suggests the subject matter 
of these clauns. More specifically, by way of example, as amended. Claim 13 reads as foUows: 

13. A computer-readable medium having computer-executable 
instructions for providing management information to a device driver monitor and 
control management system that monitors information provided by and actions 
performed by the device driver and fliat issues messages to the device driver 
which, when executed, comprise; ' 

receiving an input^output request packet ("IRP") message from the device 
driver monitor and control management system, the IRP message including 
mstructions regarding data maintained by an mstrumented hardware device; 

passing the IRP to a driver library containhag software routines for 
handling the instructions of the IRP message; and 

handling the IRP message by the driver Ubrary. 

As already noted above with regard to Claim 1, neither Hyder et al. nor Senator teaches, 
discloses, or suggests a device driver monitor and control management system that monitors 
information provided by and actions performed by a device driver and that issues messages to a 
device driver. Thus, neither Hyder et al. nor Senator teaches, suggests, or discloses providmg 
management information to such a device driver monitor and control management system. Nor 
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does Cabrera etal. teach, disclose, or suggest this subject matter. In this regard, applicants 
specifically disagree vvith the Office Action's assertion that Cabrera et al.'s "cUent pn,cess" is a 
management system. Even if conrect. which appUcauts specificaUy deny. Cabrera et al.'s "client 
process" is not a device driver monitor and control system that monitors infonnation provided by 
and actions performed by a device driver and that issues messages to a device driver 

No reasons why it would have been obvious to combine the teachings of Cabrera et al 
^VIth the teachings of Hyder et al. and Senator are presented in the Office Action, and applicants 
mamtam that there is no motivation to combine such teachings, Further, even if combinable 
which apphcants respectfully deny, the resulting combination would not anticipate the recitations 
of mdependent Claims 13, 21. and 23 for the reasons discussed above with respect to Claims 1 
20, and 22. None of the cited and applied references discloses, teaches, or even remotely 
suggests receivmg an input/output request packet ("IRP") message from a device driver monitor 
and control management system that monitors information provided by and actions performed by 
a device driver and that issues messages to a device driver as recited in Claims 13, 21, and 23 
As neither Hyder et al.. Senator, nor Cahrera et al., alone or in combination, teaches, discloses or 
suggests any IRP message &om or to such a device driver monitor and control management 
system. Claims 13, 21, and 23 are submitted to be allowable. 

As Claims 14-19 all depend from Claim 13, Claims 14-19 are submitted to be allowable 
for at least the reasons noted above with respect to Claim 13. Claims 6 and 10-1 1 all depend 
from Claim 1 and are submitted to be allowable for at least the reasons noted above with respect 
to Claim 1. 

Furfliermore, Claims 6, 10-11, and 14-19 include recitations lhat further distinguish them 
from the teachings of Hyder etal.. Senator, and Cabrera etai. and, thus, are submitted to be 
allowable for additional reasons. For example. Claim 11, which depends from Claim 1, recites 
"the driver library is furfher configured to receive, from the device driver, an identifier for a 
particular IRP, to execute a particular software routine related to handling the IRP and to return 
to the device driver monitor and control management system any mformation received from 
the hardware device as a result of handling the IRP" (emphasis added]. As noted in a prior 
response, neither Hyder etal. nor Cabrera etal. teaches, discloses, or suggests returning to a 
device driver monitor and control management system any information retrieved from a 
hardware device, regardless of the form of the information. Nor does Senator disclose this 
subject matter. Accordingly, Claim 1 1 is submitted to be allowable for this reason as well. 

As a further example, Claim 19, which depends from Claim IS (which depends from 
Claim 13) recites "the driver library is ftirther configured to format data received from the device 
driver in a fotmat consistent with the device driver monitor and control management system." 
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Hyder etal. merely teaches "decoding and branching to the applicable operative procedure " 
Nowhere does Hyder et al. teach data formatted into a format consistent Avith a device driver 
momtor and control management system that monitors information provided by and actions 
performed by a device driver and that issues messages to a device driver. As neither Hyder 
etal.. Senator, nor Cabrera etal. teaches, discloses, or suggests data formatted into a format 
consistent with such a device driver momtor and control management system. Claim 19 is 
submitted to be allowable for this reason as welL 

CONCLUSION 

In summary, applicants submit that Claims 1-23 are clearly aUowable in view of a lack of 
teaching or suggestion of a device driver momtor and control management system that monitor 
information provided by and actions performed by a device driver and that issues messages to a 
device driver m combination with the other recitations of these claims. 

In view of the foregoing remarks, appUcants submit that the present application is now in 
condition for allowance. Reconsideration and reexamination of this appUcation, as amended, 
allowance of the rejected claims, and passage of the application to issue at an early date are 
respectfuUy solicited. If the Examiner has any questions or comments concerning this 
application, the Examiner is invited to contact the applicants' undersigned attorney at the number 
below. 

Respectfully submitted^ 

CHRISTOISEN O'CONNOR 
JOffi^ONiKI^^SS''': 
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egistration^o. 22,178 
Direct Dial Ntl. 206.695.1702 

^ . \ ^ correspondence is being^tansmitted via fecsimilc/tf) the U.S. Patent and 

Trademaric Office, Group Art Unit 2126, Examiner T.T. Ho, at faJj^iraae number j>3.746.f^8 on Jane 10 2004 
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